home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1104 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  7.3 KB
  1. Subject: Gem List
  2. Subject: Re: Gem List
  3. Subject:  Scope of an APP_DEFS file
  4. Subject:  Re: Scope of an APP_DEFS file
  5. Subject:  Re: WinLIB/XAES Evaluation
  6. Subject:  Re: Gem List
  7. Subject:  Re: Gem List
  8. Subject:  Re: Gem List
  9. Subject:  Re: Gem List
  10. Date: Thu, 28 Jul 94 16:31 EST
  11. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  12. To: ems <gem-list@world.std.com>
  13. Subject: Gem List
  14. Message-Id: <23940728213132/0006795560PK2EM@mcimail.com>
  15. Precedence: bulk
  16.  
  17. Subject: Re: Gem List
  18.  
  19. Ofir:
  20. -----
  21. > >Wow, ESC and RETURN are dangerously easy to hit, and their results could
  22. > >be even more devastating. Let's remove these keys altogether then.
  23. > Yeah, lets get rid of the whole keyboard @-) This way you can't make any
  24. > mistakes...
  25.  
  26. Better yet, make it so you enter keys by mouse.  :-P
  27.  
  28. -- Ken Hollis (Bitgate Software)
  29. -----
  30. Subject:  Scope of an APP_DEFS file
  31.  
  32. David:
  33. ------
  34. > How far do we go with the APP_DEFS file: how many keys do we
  35. > include and so on.
  36.  
  37. It should not be limited at all.  It should be as big as it has to be, and
  38. it should be in the root directory or a standard directory, so all programs
  39. can access it that need it.  Also, I think someone should post some standard
  40. code (in C, C++, Pascal, and GfA Basic) so we can all use his/her code in
  41. our programs for APP_DEFS.
  42.  
  43. > For keys it's pretty easy, but a decent number of standard names for the 
  44. > other things (ie. BackgroundWindowClick: Right/RightLeft/Left/None) is 
  45. > essential.
  46.  
  47. No.  Don't get into the functionality of the program.  APP_DEFS was only
  48. designed to handle the keyboard equivalents of menubar actions, and some
  49. actions of the program.  It was NOT designed to handle the GUI itself.
  50.  
  51. > Dialogs in Windows (on/off)
  52.  
  53. Worthless since we all are going windowed dialogs anyway.
  54.  
  55. > Confirm on Exit/Save on Exit
  56. > Auto Save Prefs on Exit
  57.  
  58. These should be settable inside the program itself, instead of making it
  59. so that every program that uses APP_DEFS will have this set regardless of
  60. whether the user wants it set or not.  Take this into account:
  61.  
  62. Say, the user wants those two on one program, and doesn't want both of those
  63. or just one of those on another program.  To overcome this, he would have
  64. to change the configuration each time he ran the program.  You catch what
  65. I'm trying to say?  This means that he would have to CONFIGURE the program
  66. before he could even do anything!  It's just not practical.
  67.  
  68. I think that if you really wanted to get into the semantics of the program,
  69. and how the dialogs WORK, then create something like WIN_DEFS.SYS or
  70. APP_SETS.SYS.  DON'T put them in APP_DEFS.SYS, since these are for the
  71. APPLICATION DEFINITION KEYCODES!
  72.  
  73. We can come up with a new definition for APP_DEFS or WIN_DEFS at a later
  74. time, but for now, just stick with APP_DEFS.  I'll keep your ideas in mind,
  75. however.
  76.  
  77. (Sheez, I've still gotta write up that standard window-dialog proposal, too.
  78.  I've gotta revise the second part!  *ARGH*)
  79.  
  80. -- Ken Hollis (Bitgate Software)
  81. -----
  82. Subject:  Re: Scope of an APP_DEFS file
  83.  
  84. Kev:
  85. ---- 
  86. > > Dialogs in Windows (on/off)
  87. >I assume by this you mean wether the dialogs are modeless or not (since
  88. >you can't do modeless dialogs that aren't in windows without a lot of
  89. >hacking)? If that's the case then I don't think this is something you can
  90. >really switch on or off. Nor can I see any reason why a user would want it
  91. >off.
  92.  
  93. Agreed.
  94.  
  95. -- Ken Hollis (Bitgate Software)
  96. -----
  97. Subject:  Re: WinLIB/XAES Evaluation
  98.  
  99. Kev:
  100. ---- 
  101. > Its perhaps even more worrying than that, because it hints at misusing the
  102. > AES.
  103.  
  104. I don't think you have ANY idea of what you're talking about.  I am in no
  105. way "misusing" AES.  How could I *hint* at misusing a standard when I'm using
  106. all of the standard calls the same way that they are documented in the
  107. documentation, and in BOOKS?
  108.  
  109. -- Ken Hollis (Bitgate Software)
  110. -----
  111. Subject:  Re: Gem List
  112.  
  113. Kev:
  114. ---- 
  115. > And I don't think you understood what he was proposing. He doesn't need to
  116. > track the mouse, he just needs to get a message when it leaves his window.
  117. > Sounds like a job for a rectangle event, batman.
  118.  
  119. In which case you don't even need a rectangle event, wilbur.  You can just
  120. do a wind_find command, and check to see if the mouse leaves the confines
  121. of the window.  Whoa, that's tough stuff.
  122.  
  123. > No offence intended, but do you realise how obnoxious that sort of message
  124. > makes you come across as?
  125.  
  126. If it came as obnoxious, I'm sorry, but I realize already that most of us
  127. aren't even willing to TRY such a thing, only talk about how difficult it
  128. is...  "Oh, I can't do this, I can't do that."  "Have you tried?"
  129. (OBVIOUSLY not)
  130.  
  131. -- Ken Hollis (Bitgate Software)
  132. -----
  133. Subject:  Re: Gem List
  134.  
  135. Kev:
  136. ---- 
  137. >> No.  It IS that easy.  Simply trap the WM_TOPPED message.  All you have to
  138. >> do when you receive it is to:
  139. > Errmm, isn't that what I just said :-)
  140.  
  141. I read the message, and I answered it to what I understood you said.
  142.  
  143. -- Ken Hollis (Bitgate Software)
  144. -----
  145. Subject:  Re: Gem List
  146.  
  147. Kev:
  148. ---- 
  149. > Well, if you want to use my toolkit you can actually go out and buy a book
  150. > telling you all about it - XView programming manual, O'Reilly & Associates.
  151. > Sorry, couldn't resist it. Now can we stop with all this stupid "my toolkit
  152. > does whatever" business?
  153.  
  154. Well, I was only using an example.  So what if a book has been written.  For
  155. one thing, you said that you were writing another program that included the
  156. source from XView, which means that you didn't write it, so this book does
  157. not document YOUR program.  I doubt anyone would want to publish my
  158. documentation, because no one would really care.  No one would buy any more
  159. Atari books anyway.
  160.  
  161. > Well, I've learned damn quickly to love it. Just goes to show that these
  162. > things are not absolutes, doesn't it? Perhaps if we all realised that what
  163. > we personally like and dislike doesn't really matter then we'd get
  164. > something decided a whole lot quicker?
  165.  
  166. I never said these were not absolutes.  If we were to put everything on the
  167. earth that everyone else liked and wanted to see in a library, we would have
  168. a GUI the size of a gigabyte!  We JUST can't include every idea that everyone
  169. will come up with in one single library.  There's just no way.  Some people
  170. will like the way the library works, and actually code with it.  Some people
  171. won't.  That's their prerogative.
  172.  
  173. > (as well as auto-window topping.. this is a totally STUPID idea!)
  174. > Now there I agree, but I'm quite happy to let the individual user make his
  175. > own mind up. If your library enforces your likes/dislikes then its flawed.
  176.  
  177. Oh yes.  It's not impossible to do, and it's not impossible to enforce or
  178. implement.  As far as a library implementing likes/dislikes, there is nothing
  179. bad about it.  They can switch things on or off.  If it insists on
  180. implementing things that are practical AND impractical, then I have a
  181. problem with the library, and will not use it.
  182.  
  183. -- Ken Hollis (Bitgate Software)
  184. -----
  185. Subject:  Re: Gem List
  186.  
  187. Whoever (Gee, I like anonymous messages):
  188. -----------------------------------------
  189. > No, it is NOT that simple.  When you click to top a window, the message 
  190. > does not get sent until you let go of the button.  You can hold the 
  191. > button all day, and the window won't get topped until you let go of the 
  192. > button.
  193.  
  194. Have you even TRIED doing what I've proposed?  Sure, the message may not
  195. be sent until you let go of the mouse button, but you can surely trap it.
  196. Have you *tried* doing this?
  197.  
  198. Oh, and I hate to tell you...  *YES IT IS THAT SIMPLE*
  199.  
  200. -- Ken Hollis (Bitgate Software)
  201.